【面经】面试官：讲讲Redis的虚拟内存？
点击上方蓝色“冰河技术”，关注并选择“设为星标”
持之以恒，贵在坚持，每天进步一点点！
作者个人研发的在高并发场景下，提供的简单、稳定、可扩展的延迟消息队列框架，具有精准的定时任务和延迟队列处理功能。自开源半年多以来，已成功为十几家中小型企业提供了精准定时调度方案，经受住了生产环境的考验。为使更多童鞋受益，现给出开源框架地址：
https://github.com/sunshinelyz/mykit-delay
PS: 欢迎各位Star源码，也可以pr你牛逼哄哄的代码。
写在前面
Redis作为分布式缓存的标配，在开发分布式和微服务系统时被广泛应用。但是，很少有小伙伴会去了解有关Redis的虚拟内存。这不，一哥们出去面试就被问到这个问题。今天，我们就一起来聊聊Redis的虚拟内存。
关于Redis
与大多数的NoSQL数据库一样，Redis同样遵循了Key/Value数据存储模型。但是在有些情况下，Redis会将Keys/Values保存在内存中以提高数据查询和数据修改的效率，但是，这种方式也不是最优的。我们可以进一步优化，尽量在内存中只保留Keys的数据，这样可以保证数据检索的效率，而Values数据在很少使用的时候则可以被持久化到磁盘。
在实际的应用中，大约只有10%的Keys属于相对比较常用的键，这样Redis就可以通过虚拟内存将其余不常用的Keys和Values持久化到磁盘上，而一旦这些被持久化的Keys或Values需要被读取时，Redis则将其再次读回到主内存中。
应用场景
对于大多数数据库而言，最为理想的运行方式就是将所有的数据都加载到内存中，而之后的查询操作则可以完全基于内存数据完成。但是，在现实中这样的场景并不多，更多的情况则是只有部分数据可以被加载到内存中。
在Redis中，有一个非常重要的概念，即keys一般不会被交换，所以如果你的数据库中有大量的keys，其中每个key仅仅关联很小的value，那么这种场景就不是非常适合使用虚拟内存。如果恰恰相反，数据库中只是包含少量的keys，而每一个key所关联的value却非常大，那么这种场景对于使用虚拟内存就非常合适了。
在实际的应用中，为了能让虚拟内存更为充分的发挥作用以帮助我们提高系统的运行效率，我们可以将带有很多较小值的Keys合并为带有少量较大值的Keys。其中最主要的方法就是将原有的Key/Value模式改为基于Hash的模式，这样可以让很多原来的Keys成为Hash中的属性。
配置Redis虚拟内存
（1）在配置文件中添加以下配置项，以使当前Redis服务器在启动时打开虚拟内存功能。
vm-enabled yes
（2）在配置文件中设定Redis最大可用的虚拟内存字节数。如果内存中的数据大于该值，则有部分对象被持久化到磁盘中，其中被持久化对象所占用的内存将被释放，直到已用内存小于该值时才停止持久化。
vm-max-memory (bytes)
Redis的交换规则是尽量考虑"最老"的数据，即最长时间没有使用的数据将被持久化。如果两个对象的age相同，那么Value较大的数据将先被持久化。需要注意的是，Redis不会将Keys持久化到磁盘，因此如果仅仅keys的数据就已经填满了整个虚拟内存，那么这种数据模型将不适合使用虚拟内存机制，或者是将该值设置的更大，以容纳整个Keys的数据。在实际的应用，如果考虑使用Redis虚拟内存，我们应尽可能的分配更多的内存交给Redis使用，以避免频繁的将数据持久化到磁盘上。
（3）在配置文件中设定页的数量及每一页所占用的字节数。为了将内存中的数据传送到磁盘上，我们需要使用交换文件。这些文件与数据持久性无关，Redis会在退出前会将它们全部删除。由于对交换文件的访问方式大多为随机访问，因此建议将交换文件存储在固态磁盘上，这样可以大大提高系统的运行效率。
vm-pages 134217728
vm-page-size 32
在上面的配置中，Redis将需要持久化的文件划分为vm-pages个页，其中每个页所占用的字节为vm-page-size，那么Redis最终可用的交换文件大小为：vm-pages * vm-page-size。由于一个value可以存放在一个或多个页上，但是一个页不能持有多个value，鉴于此，我们在设置vm-page-size时需要充分考虑Redis的该特征。
（4）在Redis的配置文件中有一个非常重要的配置参数，即：
vm-max-threads 4
该参数表示Redis在对交换文件执行IO操作时所应用的最大线程数量。通常而言，我们推荐该值等于主机的CPU cores。如果将该值设置为0，那么Redis在与交换文件进行IO交互时，将以同步的方式执行此操作。
Redis同步数据方式
对于Redis而言，如果操作交换文件是以同步的方式进行，那么当某一客户端正在访问交换文件中的数据时，其它客户端如果再试图访问交换文件中的数据，该客户端的请求就将被挂起，直到之前的操作结束为止。特别是在相对较慢或较忙的磁盘上读取较大的数据值时，这种阻塞所带来的影响就更为突兀了。
然而同步操作也并非一无是处，事实上，从全局执行效率视角来看，同步方式要好于异步方式，毕竟同步方式节省了线程切换、线程间同步，以及线程拉起等操作产生的额外开销。特别是当大部分频繁使用的数据都可以直接从主内存中读取时，同步方式的表现将更为优异。
至于最终选用哪种配置方式，最好的方式是不断的实验和调优。
重磅福利
微信搜一搜【冰河技术】微信公众号，关注这个有深度的程序员，每天阅读超硬核技术干货，公众号内回复【PDF】有我准备的一线大厂面试资料和我原创的超硬核PDF技术文档，以及我为大家精心准备的多套简历模板（不断更新中），希望大家都能找到心仪的工作，学习是一条时而郁郁寡欢，时而开怀大笑的路，加油。如果你通过努力成功进入到了心仪的公司，一定不要懈怠放松，职场成长和新技术学习一样，不进则退。如果有幸我们江湖再见！
另外，我开源的各个PDF，后续我都会持续更新和维护，感谢大家长期以来对冰河的支持！！
写在最后
如果你觉得冰河写的还不错，请微信搜索并关注「 冰河技术 」微信公众号，跟冰河学习高并发、分布式、微服务、大数据、互联网和云原生技术，「 冰河技术 」微信公众号更新了大量技术专题，每一篇技术文章干货满满！不少读者已经通过阅读「 冰河技术 」微信公众号文章，吊打面试官，成功跳槽到大厂；也有不少读者实现了技术上的飞跃，成为公司的技术骨干！如果你也想像他们一样提升自己的能力，实现技术能力的飞跃，进大厂，升职加薪，那就关注「 冰河技术 」微信公众号吧，每天更新超硬核技术干货，让你对如何提升技术能力不再迷茫！